home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15072 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.5 KB
  1. Path: news.clark.net!usenet
  2. From: budge@clark.net (Joe Budge)
  3. Newsgroups: comp.lang.c++
  4. Subject: HELP! GPFs under BC4.x w/ arrays near size_t
  5. Date: 3 Apr 1996 15:07:10 GMT
  6. Organization: Clark Internet Services, Inc.
  7. Message-ID: <4ju46u$qks@clarknet.clark.net>
  8. NNTP-Posting-Host: budge.clark.net
  9. Mime-Version: 1.0
  10. X-Newsreader: WinVN 0.93.14
  11.  
  12. I am debugging several routines which use dynamic arrays of
  13. single-byte data (char is one example).  I manage array allocation
  14. with the standard new and delete operators. Simple routines which
  15. otherwise work fine start throwing GPF's or running into blown
  16. pointers and heap corruption when the array size begins to approach
  17. size_t under 16-bit Windows (64K). By "simple" I mean lines like
  18. "x = myarray[i];", which in one routine blows up if i >= UINT_MAX - 64.
  19. This behavior happens under both BC 4.0 and 4.53.
  20.  
  21. The only clue I've been able to dig up is from the Programmer's Guide
  22. which, in the chapter on Windows programming, says that "Each global
  23. memory block carries an overhead of at least 20 bytes."  "At least"
  24. is a bit vague...
  25.  
  26. Since a global memory block can be up to 1MB (I'm compiling for
  27. a 286 target), it doesn't seem to make sense that this overhead
  28. should come out of the hide of my array.  Nevertheless, I'm pretty
  29. sure that my arrays are running into _something_ before they get
  30. to size_t and I haven't been able to figure out what.  And that means
  31. I don't know how far away from size_t I need to be in order to stay
  32. safe.
  33.  
  34. If anyone can offer any insight into this issue I would greatly
  35. appreciate it.
  36.  
  37. Thanks,
  38. Joe Budge
  39.  
  40.